1.1.5. Vendor 6 Observations
In summary the test event was very useful for us. From a CalDAV perspective all products are still in very early stages (IMHO). The event showed quite a few serious issues in the CalDAV layer of all products. For me this was a reason why we couldn’t do that much ‘formal’ testing. We always ran into issues to be solved quite quickly. What I basically did was:
test against Vendor 2
initially the server ‘crashed’ (500 HTTP error) on some requests sent by us, but Simon was able to rather quickly fix this
we tested a bit of implicit scheduling, this worked quite well
test against the VENDOR 3
LDAP<→CardDAVgatewaythe VENDOR 3 CardDAV gateway was in its very early stages, so I worked with Mike to improve it
at the end of the IOP we could get/edit contacts in the server.
also discussed issues with cross-server CalDAV result sets, which VENDOR 3 seems to be using and which seems to break many clients (didn’t manage to test it). Cyrus suggested to use WebDAV Binds instead.
test against Vendor 5
this server was a bit slow (requiring ~20s to update a record), but was the only one which didn’t produce 500 errors :-)
didn’t test that much on it, but the shallow testing I did, was OK
test against Vendor 1
we found issues in the ‘principal discovery’, when trying to query the root of the server
this seems to be a rather ‘generic’ issue which produces interop issues
We tested implicit scheduling and found a bug in our Vendor 1 code which we fixed on site.
Discussed the implementation of WebDAV
XMPP.(BTW: Vendor 1 didn’t bring its new CardDAV server, but we successfully tested that before)
The table below shows the CALDAV testing matrix items tested by Vendor 6 against the Vendor 1 server.
1. | Event creation. | ||
|---|---|---|---|
P | 1.1. | Create new single-instance meeting titled “Meeting 1.1” with the location “Durham”. | |
P | 1.2. | Create new meeting titled “Meeting 1.2” recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks. | |
P | 1.3. | Create new single-instance meeting titled “Meeting 1.3” with 2 other attendees. | |
P/N | 1.4. | Create new single-instance meeting titled “Meeting 1.4” with an alarm set to trigger 15 minutes prior to the schedule time of the meeting. | alarm not exported, but stored locally, won’t trigger alarms in secondary folders |
2. | Event modification | ||
P | 2.1. | Modify the title of meeting “Meeting 1.1” to “Meeting 1.1bis”. | |
P | 2.2. | Modify the location of the meeting “Meeting 1.1bis” to “Seattle bis”. | |
P | 2.3. | Reschedule meeting “Meeting 1.1bis” to the next day. | |
P | 2.4. | Add an attendee to “Meeting 1.1bis”. | does not prompt to send an email |
P | 2.5. | Add an alarm to “Meeting 1.1bis”. | alarm not exported, but stored locally, won’t trigger alarms in secondary folders |
N | 2.6. | Modify the title of the 1st instance of the recurring meeting created in 1.2. | recurrence exceptions still unsupported |
P | 2.7. | Modify the participation status of the 1st attendee in meeting 1.3 to | Partstat panel does not show up (hm). Had to press ‘send invitations’ to make it show up. Then it worked for a Vendor 1 server external participant (plain email) |
N | 2.8. | Cancel the 4th instance of the recurring meeting created in 1.2. | recurrence exceptions still unsupported |
P | 2.9. | One client changes “Meeting 1.1bis” to a different time, second client ‘refreshes’ its display to see the modification. | Prompts the user and reminds that the reminder won’t be triggered. |
3. | Event retrieval | ||
N | 3.1. | calendar-query | not used in Vendor 6 |
N | 3.1.1. | No filtering (match everything) | not used in Vendor 6 |
N | 3.1.1.1. | Query all components and return all data. (tests | not used in Vendor 6 |
N | 3.1.1.2. | Query all components and return ETag WebDAV property and all data. (tests | not used in Vendor 6 |
N | 3.1.1.3. | Query all components and return just entire | not used in Vendor 6 |
N | 3.1.1.4. | Query all components and return | not used in Vendor 6 |
N | 3.1.2. | time-range filtering | not used in Vendor 6 |
N | 3.1.2.1. | Query all components within a one day time-range and return all data. Make sure that there is a recurring event that starts prior to the chosen time-range but has one non-overridden instance within the time-range. (tests | not used in Vendor 6 |
N | 3.1.2.2. | Query all components within a one week time-range and return just entire | not used in Vendor 6 |
N | 3.1.3. | component based filtering | not used in Vendor 6 |
N | 3.1.3.1. | Query all components that contain an embedded | not used in Vendor 6 |
N | 3.1.3.2. | Query all components that contain an embedded | not used in Vendor 6 |
N | 3.1.4. | property based filtering | not used in Vendor 6 |
N | 3.1.4.1. | Query all components that contain any | not used in Vendor 6 |
N | 3.1.4.2. | Query all components that contain an | not used in Vendor 6 |
N | 3.1.4.3. | Query all components that contain an | not used in Vendor 6 |
N | 3.1.5. | parameter based filtering | not used in Vendor 6 |
N | 3.1.5.1. | Query all components that contain a | not used in Vendor 6 |
N | 3.1.5.2. | Query all components that contain an | not used in Vendor 6 |
P | 3.2. | calendar-multiget | used and works |
P | 3.2.1. | Query a specific | |
P | 3.2.2. | Query multiple | hard to trigger in the Vendor 6 plugin, but works |
P | 3.2.3. | Query a specific | used and works |
P | 3.2.4. | Query multiple | hard to trigger in the Vendor 6 plugin, but works |
N | 3.2.5. | Query a specific | not used in Vendor 6 |
N | 3.2.6. | Query multiple | not used in Vendor 6 |